49 research outputs found

    RAPID WEBGIS DEVELOPMENT FOR EMERGENCY MANAGEMENT

    Get PDF
    The use of spatial data during emergency response and management helps to make faster and better decisions. Moreover spatial data should be as much updated as possible and easy to access. To face the challenge of rapid and updated data sharing the most efficient solution is largely considered the use of internet where the field of web mapping is constantly evolving. ITHACA (Information Technology for Humanitarian Assistance, Cooperation and Action) is a non profit association founded by Politecnico di Torino and SITI (Higher Institute for the Environmental Systems) as a joint project with the WFP (World Food Programme). The collaboration with the WFP drives some projects related to Early Warning Systems (i.e. flood and drought monitoring) and Early Impact Systems (e.g. rapid mapping and assessment through remote sensing systems). The Web GIS team has built and is continuously improving a complex architecture based entirely on Open Source tools. This architecture is composed by three main areas: the database environment, the server side logic and the client side logic. Each of them is implemented respecting the MCV (Model Controller View) pattern which means the separation of the different logic layers (database interaction, business logic and presentation). The MCV architecture allows to easily and fast build a Web GIS application for data viewing and exploration. In case of emergency data publication can be performed almost immediately as soon as data production is completed. The server side system is based on Python language and Django web development framework, while the client side on OpenLayers, GeoExt and Ext.js that manage data retrieval and user interface. The MCV pattern applied to javascript allows to keep the interface generation and data retrieval logic separated from the general application configuration, thus the server side environment can take care of the generation of the configuration file. The web application building process is data driven and can be considered as a view of the current architecture composed by data and data interaction tools. Once completely automated, the Web GIS application building process can be performed directly by the final user, that can customize data layers and controls to interact with the

    Vector-raster server-side analysis: a PostGIS benchmark

    No full text
    Report generation from coverages around points of interest (POIs) or in areas of interest (AOIs) is a common need in thematic research projects. The extracted information adds value to the POIs or AOIs dataset by enriching its information content. In a common scenario, POIs or AOIs are usually vector data whereas background thematic datasets are often raster data. The paper investigates different approaches for zonal statistic computation about both raster and vector data with particular focus on server-side free and open source software (FOSS)-based solutions. Extensive performance tests are based on PostGIS (the spatial extension of popular PostgreSQL (http://www.postgresql.org/) FOSS DBMS) 2.0. This version is the first to offer raster support. Previously, vector-raster analysis was not supported by any FOSS DBMS environment and such analyses were possible in a FOSS server-side environment using geographical information system( GIS) tools (e.g., Geographic Resources Analysis Support System (GRASS) GIS) and Open Geospatial Consortium (OGC) Web Processing Server. PostGIS performance data from the tests are compared to an almost standard ESRI ArcGIS desktop approach. A project aimed at monitoring fire alerts in African protected areas provides the benchmarking application. The computation of people living in the surroundings of POIs (alert points from Global Fire Information Management System) based on a world population density dataset (LandScan) is the benchmarking query. The impact of many parameters on performances is considered: the adopted tile size in the storing of the raster in the DBMS, the dimension of queried areas in relation to the abovementioned tile size, the number of queried features
    corecore